Write a travel policy people actually follow

The typical travel policy at a company of forty people is a nine-page PDF written by someone who has since left. It is thorough, and nobody has read it. People book what seems reasonable and hope finance agrees.

That is not a discipline problem. It is a writing problem. A policy people follow is short enough to remember and specific enough to apply without asking.

Start with five lines

Most of what a policy needs to say fits in five lines, and the rest is exceptions. Ours, for a team that travels a few times a month, looks like this:

• Hotels up to $190 a night, $240 in New York and San Francisco.
• Economy for flights under five hours, with a refundable fare.
• The train before the plane for trips under four hours.
• The city's per diem for meals, every travel day.
• Anything over the trip's budget goes to whoever owns that budget.

Each line names a category, a limit and, implicitly, what happens at the limit. That last part is where most policies go quiet.

Say how hard each line is

Not every rule is the same kind of rule. A hotel cap is usually a hard line: over it, someone has to say yes. A preference for the train is a soft one: it should be offered first, and a person can still choose the flight without asking anyone.

Write the difference down. We use three words.

• Hard cap. Over the line needs an approval.
• Soft limit. Offered first, logged if someone goes past it, no approval needed.
• Ask. Always goes to a named person.

Once a rule says which of the three it is, nobody has to guess whether the $205 room is a problem.

Name the person, not the department

"Approved by finance" means approved by nobody in particular, which means approved late. A policy should name who decides for each budget: the team lead for team trips, the founder for the offsite, the regional lead for customer visits. When the request comes, it goes straight to them.

An exception that waits three days for an answer is not an exception. It is a booking that got more expensive.

Offer the alternative with the exception

The single change that made our approvals faster was attaching a compliant option to every request. "The Hotel Caliche is $41 over the cap. The Arbor, two blocks away, is inside it." Most approvers pick in seconds, and about half of them pick the cheaper room.

Put it where people book

A policy that lives in a document is checked after the fact, by someone who has to say no to a trip that already happened. A policy that lives where the booking happens is checked before, by the tool, and the traveler only hears about it when a line is crossed. Pioneer reads the five lines above on every fare and every room, which is why nobody on our team has opened our own policy since we wrote it.

Review it twice a year

Rates change, cities change and teams change. Twice a year, look at the exceptions you approved. If the same rule was broken for the same reason more than a handful of times, the rule is wrong, not the travelers. Raise the cap in Austin, add a city, drop a line nobody needed.

A policy that is short, specific and maintained gets followed without anyone enforcing it. That is the only kind worth writing.